Do you remember what the exact deadlock situation was?

Reading levelChunk and the sections array without an appropriate lock sounds a bit dangerous, though I'm not fully sure about the details.

Do you remember what the exact deadlock situation was?

Reading levelChunk and the sections array without an appropriate lock sounds a bit dangerous, though I'm not fully sure about the details.

Deadlock was reported by a user in august specifically on trimming. It seems to be a relatively rare circumstance that can lead to the specific trim settings which is why it's not been reported till now, but looking at the old code it was possible for a deadlock.

Is there a specific place you think we should be locking? I believe the methods called from here lock where it would be suitable to do so

I don't have anything specific in mind, but I'd like to better understand the situation in which the deadlock was able to occur. Other than that, it's generally just rather difficult to keep track which lock is acquired where.

I don't have anything specific in mind, but I'd like to better understand the situation in which the deadlock was able to occur. Other than that, it's generally just rather difficult to keep track which lock is acquired where.

Basically, trim synchronised on the instance and then locked the sectionLock. internallCall did it the opposite way round (it locked the sectionLock before calling getChunk which synchronises on the instance if this.levelChunk is null (which it will be when we're trimming a lot))

Basically, trim synchronised on the instance and then locked the sectionLock. internallCall did it the opposite way round (it locked the sectionLock before calling getChunk which synchronises on the instance if this.levelChunk is null (which it will be when we're trimming a lot))

Thanks.